REMARKS 

Reconsideration and allowance of the above-referenced application are respectfully 
requested. Claim 10 is amended, and claims 1-9 and 11-13 are unchanged. Claims 1-13 are 
pending in the application. 

Claim 10 is amended to correct an informality; hence, the amendment is "cosmetic" in 
nature and does not affect the scope of the claim. 

Claims 1 and 10 stand rejected under 35 USC § 102(e) in view of U.S. Patent No. 
6,094,435 to Hoffman. This rejection is respectfully traversed. 

The rejection is legally inadequate because the Official Action fails to demonstrate how 
Hoffman discloses each and every element of the claim. In particular, independent claims 1 and 
10 specify " determining an application state for a prescribed network application from a received 
layer 2 data packet" and " determining an application state for a detected one of a plurality of 
prescribed network applications from a received layer 2 data packet," respectively. 

Further, independent claims 1 and 10 specify "selectively deleting an address entry ... 
based on the determined application state ." As described in the specification, the term "network 
application" refers to higher-protocol communications (i.e., above layer 2) between two network 
nodes that involve multiple "application states": network nodes communicate according to a 
prescribed network application (e.g., OSI Layer 7 ("Application Layer") protocols such as 
HTTP, SNMP, FTP, Telnet, etc.), resulting in prescribed data flows between the two network 
nodes; hence, the layer 2 data packets transferred between the network nodes will include 
payload information that specifies the prescribed network application state, for example a request 
to initiate a session, acknowledgment, communication during the session, a request to terminate 
the session, and acknowledgment of termination of the session. 

Hence, the claimed determining of an application state by the network switch enables the 
network switch to identify the presence of data flows between network nodes according to the 
prescribed network application, enabling the integrated network switch to adjust aging timers 
according to the prescribed network application parameters. Moreover, the selective deletion of 
the address entry based on the determined application state enables the network switch to delete 
the address entry upon determining from the application state that the data flows between the 
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network nodes is terminated, for example at the end of a session between the two nodes. Hence, 
the deletion of address entries can be precisely controlled based on the completion of a network 
application session, as determined by the application state from the received layer 2 data packet. 

These and other features are neither disclosed nor suggested by the applied prior art. 

Hoffrnan neither discloses nor suggests the claimed determining an application state for a 
prescribed network application, let alone selectively deleting an address entry based on the 
determined application state, as claimed. 

In particular, the Office Action asserts that: 

Destination aging in the network element indicates which layer 2 and layer 3 entries are 
active (determine an application state). The information implements in accordance with 
IEEE standard 802. Id type address aging (delete an address entry from a network switch 
address table based on the application state) (column 16, lines 43-53). 

This tortured interpretation is inconsistent with the teachings of the reference, which 
specifies at column 16, lines 43-53 that: 

The entry also contains information relating to source and destination aging. Source aging 
information indicates whether the source is active or not. In a preferred implementation, 
this information is updated by the forwarding logic 52 every time the layer 2 source 
address is matched . The information implements in accordance with IEEE standard 
802 Id type address aging. Destination aging in the network element 12 indicates which 
layer 2 and layer 3 entries are active. The information for an entry is updated every time 
an entry is matched , either by a layer 2 destination search or a layer 3 match cycle for the 
entry. 

(Emphasis added). 

Hence, Hoffman explicitly teaches that aging is based on identifying whether a matching 
address is found within a specified aging interval, in accordance with IEEE 802.1D. As shown 
in the attached Exhibit A (page 2), the IEEE 802.1D Specification (1998) specifies on page 45 
that entries "shall be automatically removed after a specified time, the Ageing [sic] Time, has 
elapsed since the entry was created or last updated." Further , Table 7-4 of the IEEE 802.1D 
Specification specifies a range of applicable aging parameter values with a recommended default 
value . 

Hence, Hoffman merely discloses that aging is based on whether a matching address 
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(layer 2 or layer 3) is detected before expiration of the aging interval, and describes no more than 
the Background Art described on pages 1-2 of the specification. 

Moreover, Hoffman states that "[t]he relevant layers for describing this invention include 
OSI Layers 1 through 4" (col. 2, lines 5-6). Hoffman makes no reference whatsoever to any kind 
of state, let alone any determination nf «n application state for a network application , as claimed. 
As recognized by one skilled in the art, any session interactions that could be considered as an 
application state between application processes on respective network endnodes are not 
performed below the Session Layer (Layer 5). (See page 2 of the attached Exhibit 2). 

Hence, Hoffman neither discloses nor suggests the claimed determining an application 
state for a prescribed network application from a received layer 2 data packet. 

Moreover, the Examiner is respectfully reminded that the broadest reasonable 
interpretation of "determining an application state for a prescribed network application" cannot 
be inconsistent with the specification, which describes that network nodes communicate 
according to the prescribed network application, where the layer 2 data packets transferred 
between the network nodes will include payload information that specifies the prescribed 
network application state, for example a request to initiate a session, acknowledgment, 
communication during the session, a request to terminate the session, and acknowledgment of 
termination of the session (see, e.g., page 7, line 32 to page 8, line 1 1 of the specification). 

Hence, "claims are not to be read in a vacuum, and limitations therein are to be 
interpreted in light of the specification in giving them their 'broadest reasonable interpretation.'" 
MPEP§ 2111.01 at 2100-37 (Rev. l,Feb. 2000) (quoting In re Marosi, 218 USPQ 289, 292 
(Fed. Cir. 1983)(emphasis in original)). 

For these and other reasons, the §102 rejection of claims 1 and 10 should be withdrawn. 
Claim 2 stands rejected under 35 USC §103(a) in view of Hoffman and U.S. Patent No. 
5,128,926 to Permian. This rejection is respectfully traversed: the Official Action 
mischaracterizes the teachings of Perlman by suggesting that "link state" teaches the claimed 
"application state". 

In particular, Perlman explicitly teaches that "[t]he invention relates to updating link state 
information in networks." (Col. 1, lines 18-19). The link state information refers to whether a 
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link is operative or inoperative. As described above and illustrated in Exhibit B (page 1), the 
Data Link Layer (Layer 2) is directed to transfer of data: Perlman is concerned that "each router 
must know the states (e.g., operative or inoperative) of the links in the network in order to send 
packets along effective paths to their respective destinations, avoiding, for example, faulty hnks 
or rou ters ." Hence, Perlman neither discloses nor suggests the claimed determining the 
application state. 

Regardless, the rejection fails to establish a prima facie case of obviousness because the 
rejection fails to show how Perlman teaches the claimed feature of claim 2: storing within a 

.witch nort a ridity of templates configured for identifying the application state from 
r . T ^^i,hl. Plication states of the prescribed network application. The rejection 
merely cites Perlman at col 1, lines 1-28 regarding the description of link status, and does not 
address the claimed templates. 

For these and other reasons, the §103 rejection of claim 2 should be withdrawn. 
Claims 8-9 and 1 1 stand rejected under §103(a) in view of Hoffman and U.S. Patent No. 
6,104,696 to Kadambi. This rejection is respectfully traversed. As described on page 1, line 20 
to page 2, line 5 of the specification, the use of a "hit bit" is a conventional layer 2 operation for 
resetting the fixed aging timer specified by the IEEE 802.1D Specification (See Exhibit A). 

Claims 8 and 1 1 , however, specify an application-specific aging timer configured for 
counting the application-specific aging interval. Neither Hoffman or Kadambi, singly or in 
combination, disclose nor suggest an application-specific aging timer configured for counting the 
application-specific aging interval for a prescribed network application, as claimed. For these 
and other reasons, claims 8-9 and 1 1 are patentable over Hoffman and Kadambi. Hence, this 
§103 rejection should be withdrawn. 

The indication of allowable subject matter in claims 3-7 and 12-13 is acknowledged and 
appreciated. It is believed these claims are allowable in view of the foregoing. 

In view of the above, it is believed this application is and condition for allowance, and 
such a Notice is respectfully solicited. 
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To the extent necessary, Applicant petitions for an extension of time under 37 C.F.R. 
1 136 Please charge any shortage in fees due in connection with the filing of this paper, 
including any missing or insufficient fees under 37 C.F.R. 1.17(a), to Deposit Account No. 
50-0687, under Order No. 95-307, and please credit any excess fees to such deposit account. 

Respectfully submitted, 
Manelli Denison &Jjelter, PLLC 

Leon R. Turkevich 
Registration No. 34,035 



Customer No. 20736 

2000 M Street, N.W., 7 ,h Floor 

Washington, DC 20036-3307 

(202) 261-1000 

Facsimile (202) 887-0336 

Date: October 14, 2003 
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